Method of controlling a queue buffer by performing congestion notification and automatically adapting a threshold value

ABSTRACT

A method of controlling a queue buffer ( 2 ), said queue buffer ( 2 ) being connected to a link ( 1 ) and being arranged to queue data units ( 30 ) that are to be sent over said link ( 1 ) in a queue ( 20 ), comprising: determining (S 1 ) a value (QL; QL?av# 191 ) of a length parameter related to the length of said queue ( 20 ), comparing (S 2 ) said value (QL; QL?av# 191 ) with a length threshold value (L?th# 191 ; min?th# 191 ; max?th# 191 ) and performing (S 3 ) a congestion notification procedure if said value (QL; QL?av# 191 ) is equal to or greater than said length threshold value (L?th# 191 ; min?th# 191 ; max?th# 191 ), and an automatic threshold adaptation procedure (S 4 , S 7 ), where said automatic threshold adaptation procedure (S 4 , S 7 ) is arranged to automatically adapt said length threshold value (L?th# 191 ; min?th# 191 ; max?th# 191 ) on the basis of one or more characteristics of said link ( 1 ).

FIELD OF THE INVENTION

The present application relates to a method of controlling a queuebuffer, said queue buffer being connected to a link and being arrangedto queue data units that are to be sent over said link.

BACKGROUND OF THE INVENTION

In data unit based communication, i.e. in which an information to betransmitted is divided into a plurality of units, and the individualunits are sent over a communication network, its is known to providequeue buffers at links along the network, such that units transportedover such a link may be buffered. The buffer may be a sending or inputbuffer (i.e. a buffer for data units that are to be sent over the link)or a receiving or output buffer (i.e. a buffer for data units that havebeen sent over the link).

Such units for transporting data may carry a variety of names, such asprotocol data units, frames, packets, segments, cells, etc., dependingon the specific context, the specific protocol used and certain otherconventions. In the context of the present document, all such units ofdata shall generically be referred to as data units.

The procedures for placing data units into a queue, advancing them inthe queue, and removing data units from the queue are referred to asqueue management.

A phenomenon that is known in data unit transmission networks is that ofso-called congestion. Congestion implies a state in which it is notpossible to readily handle the number of data units, that are to betransported over that connection or link. As a consequence of congestionat a given link, the number of data units in a queue buffer associatedwith said link will increase. In response to a congestion condition, itis known to implement a data unit dropping mechanism referred to asdrop-on-full, according to which upon the receipt a new data unit forthe queue buffer, a queue length related parameter, such as the actualqueue length or the average queue length, is compared to a predeterminedthreshold, and if the predetermined threshold is exceeded, then a dataunit is dropped. The threshold indicates the full state of the queue.“Dropping” means that it is not placed into the queue and consequentlynot transported further.

The data unit to be dropped can be the newly arrived one, in which casethe mechanism is called tail-drop. Besides the technique of tail-drop,it is also known to perform a so-called random-drop, where a data unitalready in the queue is selected according to a random function, or aso-called front-drop, where the first data unit in the queue is dropped.Such drop-on-full mechanisms not only serve to reduce the load on thecongested link, but also serve as an implicit congestion notification tothe source and/or destination of the data unit. Namely, as e.g. knownfrom TCP (Transmission Control Protocol), congestion control mechanismsare typically implemented with respect to the receiver and sender ofdata units, such that when detecting that a data unit has been lost, therate and/or amount of data units being sent is reduced.

Besides such queue managements systems that start dropping data unitsonce a predetermined threshold is exceeded, i.e. when the queue isdetermined to be “full”, a more sophisticated management scheme has alsobeen proposed, which is known as active queue management and isdescribed in Request for Comments (RfC) 2309. More specifically RfC 2309proposes an active queue management mechanism referred to as RandomEarly Detection (RED). The concept of RED according to RfC 2309 consistsin the recognition that it is useful to not wait until a queue is full,but to much rather implement a mechanism that leads to a dropping ofsome packets prior to reaching the full state.

According to RfC2309, the RED algorithm consists of two main parts,namely first estimation of the average queue size and then a decision ofwhether or not to drop an incoming data unit. More specifically, when anew data unit arrives, the algorithm estimates the average queue size,and if the average queue size lies between a minimum threshold min_(th)and a maximum threshold max_(th), then a probability value is calculatedas a function of the average queue size, and the decision regarding thedropping of the incoming data unit is performed in dependence of theresulting probability. If the average queue size exceeds the maximumthreshold maxth, then the incoming data unit is necessarily dropped. Theprobability funtion is a linear function that has a value p(min_(th))=0,and where p(max_(th)) is a predetermined maximum probability max_(p),where max_(p) is smaller than 1.

Regarding the choice of the minimum threshold min_(th) or the maximumthreshold max_(th), RfC2309 does not give any information.

In the paper “Random Early Detection Gateways for Congestion Avoidance”by Sally Floyd and Van Jacobson, IEEE/ACM Transactions on networking,August 1993, an extensive discussion of the RED algorithm is given,where the minimum threshold min_(th), maximum threshold max_(th) and themaximum probability max_(p) are all set as fixed parameters. Regardingthe choice of min_(th) and max_(th), it is mentioned that the optimumvalues for these thresholds depend on the desired average queue size,and the optimal value for max_(th) depends in part on the maximumaverage delay that can be allowed by the link. Furthermore, it is statedthat max_(th) should at least be twice as large as min_(th).

In an internet document discussing the setting of RED parameters,published by Sally Floyd at http://www.acir.org/floyd/REDparameter.txt,it is mentioned that the optimum value for fixing min_(th) will dependpartly on the link speed, the propagation delay and the maximum buffersize.

In the article “Techniques for eliminating packet loss in congestedTCP-IP networks” by Wu-chang Feng et al., November 1997, a so-calledadaptive RED is proposed, in which the probability parameter max_(p) isadapted to the traffic load. Although the detailed algorithm describedin this document uses fixed thresholds, it is indicated at the end thatthe threshold values could also be made dependent on the input traffic.A similar proposal is made in the article “A self configuring REDgateway” by Wu-chang Feng et al., Infocom '99, March 1999.

Another proposal for improving RED is made in WO 00/60817, in which adifferentiation is introduced between traffic originating from rateadaptive applications that respond to packet loss. This documentsuggests introducing at least two drop precedent levels, referred to as“in profile” and “out profile”. Each drop precedent level has its ownminimum threshold min_(th) and/or maximum threshold max_(th).

From WO 00/57599 a queue management mechanism is known, in which dropfunctions are selected according to ingress flow rate measurements andflow profiles.

From U.S. Pat. No. 6,134,239 a method of rejecting ATM cells at anoverloaded load buffer is known. The concept of RED is mentioned.According to this document, a first threshold related to the overloadedbuffer queue, and a second threshold associated with a specificconnection are monitored, and incoming packets are dropped for thespecific connection if both thresholds are exceeded.

U.S. Pat. No. 5,546,389 describes a method for controlling the access toa buffer and is specifically concerned with ATM buffers. The use of oneor more thresholds and the dynamic control of such thresholds ismentioned, where the dynamics are determined on the basis of incomingand outgoing traffic.

EP-1 028 600 described a buffer management scheme with dynamic queuelength thresholds for ATM switches. A common threshold is dynamicallyupdated every time that a new cell arrives, where the new value isdetermined based on traffic condition.

Another improvement proposal for RED is described in EP-0 872 988, whichhas the object of providing isolation when connections using differentTCP versions share a bottleneck link. The solution proposed in thisdocument is the use of bandwidth reservation guarantees for eachconnection. If one connection is being under-utilized, then anotherconnection may use a part of the under-utilized connection's bandwidth.When the connection needs to reclaim its buffer space a predeterminedpackage dropping mechanism is operated, such as a longest queue first(LQF) mechanism.

OBJECT OF THE INVENTION

The object of the present invention is to provide an improved method ofcontrolling a queue buffer, where said method compares a queue lengthrelated parameter with a length threshold value and employs an automaticthreshold adaptation procedure.

SUMMARY OF THE INVENTION

The above object is solved by a method having the features of claim 1.Advantageous embodiments are described in the dependent claims.

According to the present invention, the automatic threshold adaptationprocedure is arranged to automatically and dynamically adapt a lengththreshold value, such as e.g. the minimum threshold min_(th) known fromRED or the single threshold known from drop-on-full queue managementschemes, on the basis of one or more characteristics of the link overwhich the data units in the queue buffer are to be sent.

Therefore, in contrast to the above discussed prior art, in which thelength threshold value was either a fixed value or adapted to thetraffic load condition, the present invention proposes automatically anddynamically adapting the length threshold on the basis of linkcharacteristics. This leads to a highly flexible form of active queuemanagement that provides improved throughput and reduced delay,especially over links that have time varying characteristics, such aswireless links.

The method of the present invention may be applied to any of the knownqueue management schemes in which a queue length related parameter iscompared to at least one length threshold value, and where a congestionnotification procedure is conducted, if the threshold is exceeded.Namely, the present method is e.g. applicable to any of the abovementioned RED schemes, to the schemes that drop data units when a queueis full, be it tail-drop, random-drop or front-drop, and to any knownschemes that perform explicit congestion notification instead ofdropping.

Furthermore, although a preferred embodiment of the present inventionapplies the method to the queuing of IP (internet protocol) packets, themethod of the present invention is not restricted to data units of anyspecific protocol, and can e.g. also be applied to queue managementmethods for ATM cells.

According to a preferred example of the present invention the one ormore link characteristics are the round trip time (RTT) of the link andthe data rate (DR) or bit rate of the link, and the threshold adaptationprocedure comprises an updating of the length threshold value as afunction of the round trip time and data rate of the link. This updatingmay be performed at regular intervals, or in response to a specifictriggering-event, such as a change in the above mentioned linkcharacteristics. In other words, in the latter alternative the thresholdvalue is updated as a function of the round trip time and the data rateevery time that the round trip time or data rate change. It may be notedthat an updating of the threshold value will not be initiated uponinfinitesimally small changes of the link characteristics underconsideration, as there will be a certain granularity. In other words,changes of the link characteristics under consideration will bemonitored, and if one of the characteristics changes by more than apredetermined step or grain size, then the threshold will be updated.

More preferably, the function for updating the threshold value consistsin calculating a link capacity value (LC) on the basis of the round triptime and the data rate, and then setting the threshold value equal tothe calculated link capacity value or at least determining the thresholdvalue as a function of said link capacity value, e.g. as the sum of saidlink capacity value and a predetermined constant.

The automatic threshold adaptation procedure may also comprise theautomatic changing of the value of the length threshold depending on theconnectivity state of the link. In other words, in this case theconnectivity sate of the link is the link characteristic on which theadaptation is based. Especially, in the event that the link losesconnectivity, i.e. can not transport data units, the length thresholdvalue is preferably automatically increased, e.g. multiplied by apredetermined factor, such as 2. The changing of the length thresholdvalue depending on the connectivity can be implemented by itself, or canbe combined with the abovementioned updating procedure of the lengththreshold depending on such link characteristics as the round trip timeand the data rate.

Preferably, the procedure of changing the length threshold value inresponse to the connectivity of the link also comprises a feature ofresetting the length threshold value after the connectivity state againallows the transmission of data units. This resetting can be done backto the previous value of the length threshold value, or a new lengththreshold value may be calculated on the basis of one or morecharacteristics, such as the above mentioned round trip time and datarate. The resetting operation preferably also takes into account thenumber of data units in the queue (the actual queue length) at the timeof resetting in order to gradually reset the length threshold value tothe new value.

The congestion notification procedure employed in association with thepresent invention can be chosen as is desirable or suitable, and anyknown implicit or explicit congestion notification procedure can beused. For example, as an implicit congestion notification procedure, adata unit dropping decision can be made, where said decision can eitherdepend on a given probability (as in the case of RED techniques) or canbe conducted unconditionally (as in the case of drop-on-fulltechniques). An example of an explicit congestion notification procedureconsists in setting an appropriate congestion flag in a data unit. Forexample, the so-called ECN (explicit congestion notification) flag inthe IP header of an IP packet can be set. Again, the decision of settingor not setting the flag can be made conditional on a predeterminedprobability function, or can be unconditional. It is also noted, thatthe congestion notification procedure employed in association with thepresent invention can be a combination of an implicit congestionnotification procedure and an explicit congestion notificationprocedure, i.e. can consist in performing decisions regarding data unitdropping and in decisions regarding the setting of explicit congestionnotification flags in data units.

As already mentioned previously, the present invention can be applied toqueue management methods that use at least one length threshold value.In other words, it can be applied to queue management methods usingdrop-on-full techniques, where the single threshold indicating a fullqueue is automatically adapted, or can be applied to queue managementmethods using a plurality of thresholds, such as RED that uses twothresholds min_(th) and max_(th). In accordance with the presentinvention, if a plurality of thresholds are employed, then it ispossible that only one of these is automatically adapted on the basis ofone or more link characteristics, while the others remain fixed, or theothers may also be adapted automatically, be it on the basis of the samecharacteristics, or be it that each threshold is adapted on the basis ofrespective individual link characteristics associated with that specificthreshold. As an example, it is possible that the minimum thresholdmin_(th) of RED is adapted on the basis of a first set of linkcharacteristics and the maximum threshold max_(th) is adapted on thebasis of a second set of link characteristics, different from said firstset.

According to a preferred embodiment, in which the method of the presentinvention is applied to RED, the minimum threshold min_(th) is updatedon the basis of the round trip time and the link data rate, and themaximum threshold max_(th) is updated on the basis of the same linkcharacteristics, namely in that the maximum threshold max_(th) is simplycalculated as the sum of min_(th) and a predetermined constant.

BRIEF DESCRIPTION OF FIGURES

The present invention shall now be described by referring to detailedembodiments thereof, which are not to be understood as restricting theinvention, which embodiments will be described by referring to theappended figures in which:

FIG. 1 shows a schematic block diagram of a queue buffer;

FIG. 2 shows a flow chart for explaining a basic embodiment of thepresent invention;

FIG. 3 shows a flow chart for explaining a more detailed embodiment ofthe present invention;

FIG. 4 shows flow chart sections for explaining different thresholdadaptation procedures;

FIG. 5 shows a flow chart for explaining an embodiment a lengththreshold change procedure depending on the link connectivity; and

FIG. 6 shows a flow chart of an embodiment of a congestion notificationprocedure.

DETAILED DESCRIPTION

FIG. 1 shows a schematic block diagram of a queue buffer 2, which isconnected to a link 1 and is arranged to queue incoming data units 30 ina queue 20, in order to transmit said data units 30 over said link 1.The queue buffer is included in an element (not shown) belonging to anetwork 3 that transports said data units 30. For example, the elementcan be a router in the network 3.

The queue buffer 2 can equally well be arranged to act as a receivingbuffer for receiving data units from the link 1, and outputting thequeued data units to the network 3

As already mentioned previously, in accordance with the presentinvention, the link 1, queue buffer 2, and data units 30 can be of anydesired type. For example, the data units 30 can be IP packets and thequeue buffer 2 can be a part of an IP router for forwarding said IPpackets. However, the queue buffer 2 can also be an ATM buffer, in whichcase the data units 30 are ATM cells.

Although the link can be of any suitable or desired type, the method ofthe present invention is preferably applied to a queue buffer connectedto a wireless link, such as a radio telephone link. For example, thelink 1 could be provided by a mobile cellular telephone network arrangedaccording to GSM (Global System for Mobile communication), UMTS(Universal Mobile Telephone System) or any other mobile communicationstandard. Namely, due to the fact that wireless links generally havetime varying characteristics, the automatic threshold adaptationprocedure on the basis of one or more link characteristics is especiallyeffective and useful.

Namely, the queue management method of the present invention caneffectively adapt to the time varying characteristics of the wirelesslink by adapting the one or more length threshold values with which aqueue length related parameter is compared in order to start acongestion notification procedure.

FIG. 2 shows a flowchart of a basic embodiment of the method of thepresent invention. In a step S1, a value of a length parameter relatedto the length of the queue 20 is determined. This queue length relatedparameter can be related to the queue length in any desirable suitableway, e.g., can be the actual or momentary queue length QL, or aparameter derived from the actual or momentary queue length, such as anaverage value QL_(av).

In the example of FIG. 2, the queue length related parameter is anaverage queue length QL_(av). This average queue length QL_(av) can bedetermined in accordance with any known or suitable averaging algorithm,and such an algorithm may typically consist in updating an old averagevalue by calculating the sum of the old average multiplied by a firstweight factor and the momentary queue length multiplied by a secondweight factor. For example, QL_(av) can be calculated asQL _(av)(new)=QL _(av)(old)×(1−½^(n))+(QL×½^(n))  (1)where QL represents a momentary queue length value and n is anexponential weight factor adjustable between 0 and 1.

Then, in step S2, QL_(av) is compared with a length threshold valueL_(th). If the length threshold value L_(th) is exceeded, then acongestion notification procedure S3 is performed, otherwise thecongestion notification procedure S3 is skipped.

In the example of FIG. 2, the flow then proceeds to an automaticthreshold adaptation procedure for L_(th), namely in step S4. Inaccordance with the present invention, this automatic thresholdadaptation procedure S4 is arranged to automatically adapt the lengththreshold value L_(th) on the basis of one or more characteristics ofthe length 1.

It may be noted that the specific arrangement of the steps shown in FIG.2 is only an example. Especially, steps S1, S2, and S3, which form aprocedure for deciding on the performing of a congestion notificationprocedure, are independent of the adaptation procedure before L_(th) ofstep S4. Consequently, steps S1, S2, and S3 may be arrangedindependently of S4, namely S4 can also be performed prior to S1–S3, orin parallel thereto. Especially, it may be noted that steps S1 to S3 onthe one hand, and step S4 on the other hand, will generally be containedin a larger method of controlling a queue buffer having more steps, butsuch additional steps are not shown, as they do not pertain to thepresent invention. The method of FIG. 2 may be implemented as software,and the steps S1–S3 can e.g. be implemented in one thread, while S4 maybe implemented in another, independent thread. However, the method canalso directly be implemented in the form of hardware.

A flowchart showing a more detailed embodiment of the present inventionis shown in FIG. 3. The steps that are identical or equivalent to thoseshown in FIG. 2 are referred to by the same reference signs, and thedescription thereof is not repeated.

It may be noted that the queue length related parameter, such asQL_(av), and the length threshold L_(th) can be expressed and measuredin any desirable or suitable way. For example, it is possible to expressthese parameters as data quantities, i.e., in bits or bytes, or theseparameters can also be expressed as numbers of data units, i.e., anactual queue length QL is expressed as an integer number of data units(due to averaging, the average queue length Ql_(av) will nonethelessgenerally not be an integer).

According to the example in FIG. 3, a session begins at a step S5.Thereafter, step S6 determines if a threshold comparison triggeringevent has occurred. If such an event has occurred, then steps S1, S2,and S3 are performed, as already explained in connection with FIG. 2. Ifnot, or after having gone through steps S1 to S3, the flow proceeds tostep S7. In step S7, it is determined if an adaptation triggering eventhas occurred, and if this is the case, then the automatic adaptationprocedure for L_(th) of step S4 is performed. If the outcome of step S7is negative, and after the completion of step S4, the flow of FIG. 3proceeds to step S8, in which it is determined if the session is to end.If the session is not to end, then the flow loops back to step S6, andotherwise the flow comes to an end.

The threshold comparison triggering event of step S6 can be chosen inany desirable or suitable way. For example, the threshold comparison ofsteps S1 to S3 can be initiated regularly, i.e., at regular intervals.In this case, the threshold comparison triggering event will, e.g., bethe occurrence of a specific timing condition, or the event that acounter reaches a specified value. As an example, a threshold comparisoncounter can be implemented, which counts down from a predetermined valueto zero, and the threshold comparison triggering event of step S6 isgiven when this counter reaches zero. If it is determined that the valueis zero, then the procedure of steps S1 to S3 is initiated, and thecounter is reset to the predetermined value, such that a new countdownwill commence.

The threshold comparison can also be triggered by events related to thereceipt or transmission of data units to the queue, or specific actionstaken with respect to individual data units in the queue. For example,the threshold comparison triggering event can consist in the release ofa data unit to the link. Preferably, the threshold comparison triggeringevent of step S6 consists in the arrival of a new data unit that is tobe buffered.

The adaptation triggering event in step S7, which leads to initiation ofthe automatic threshold adaptation procedure S4, may also be chosen asis suitable or desirable. For example, it is possible to initiate theautomatic threshold adaptation procedure at regular intervals, such thatthe adaptation triggering event in step S7 can be a certain timecondition becoming true, or the event that a counter reaches apredetermined value, as already described above in connection with thetriggering event of step S6. The two triggering events in step S6 andstep S7 can have the same regular period, or can be chosen to occur atdifferent regular intervals. In other words, the same counter can beused to determine the triggering events of steps S6 and step S7, inwhich case the two steps S6 and S7 effectively merge into a single step,or two different counters or counter values can be used thatrespectively count down different initial values.

Preferably, the adaptation triggering event of step S7 consists in achange in one or more of the link characteristics that serve as a basisfor adapting the length threshold value L_(th). It may be noted that inpractice a change will only be determined with a certain granularity. Inother words, not any ever so small change in a characteristic will beconsidered a triggering event, but much rather only when a change of apredetermined magnitude occurs.

An example of using a change in a characteristic as a triggering eventis shown in FIG. 4 a, where the illustrated steps S71 and S41 replacesteps S7 and S4 of FIG. 3. Namely, FIG. 4 a shows an example, where theautomatic threshold adaptation procedure is based upon the round triptime RTT and the data rate DR of link 1. Consequently, step S71 checksif one or both of the round trip time RTT and the data rate DR havechanged, and if this is the case, then a new value of the lengththreshold L_(th) is determined as a function of RTT and DR. It may benoted that the above mentioned round trip time RTT only relates to thelink 1, and is not an end-to-end round trip time.

As is known in the art, the round trip time RTT is a parameter that isindicative of the time period that passes between the sending of a dataunit and a receipt of an associated acknowledgement message. The RTT canbe determined in any suitable or desirable way, and especially in anyknown way. For example, the RTT is automatically measured in suchsystems that employ ARQ (Automatic Retransmission reQuest), but even insystems that do not employ ARQ, the RTT can be measured by means of anappropriate dedicated scheme, such as the sending of a dedicated RTTmeasuring signal from the sending side of link 1 to the receiving sideof link 1, where the receiving side is arranged to send back anappropriate acknowledgement message. An example of this is also known as“ping”.

Like the link's RTT, the data rate DR can also be determined in anysuitable or desired way, and especially in any known way. For example,DR can be measured by dedicated measurements, or it can also be aparameter already available from another control procedure that requiresthe DR as an input.

Preferably, the procedure for updating L_(th) in step S41 comprisesappropriately estimating a link capacity value LC on the basis of theround trip time RTT and the data rate DR. The link threshold valueL_(th) is then determined on the basis of the estimated link capacityvalue LC.

Now another embodiment of the present invention shall be described withreference to FIG. 6. In this embodiment the method of controlling aqueue buffer employs two length threshold values, a minimum thresholdmin_(th) and a maximum threshold max_(th). In this example, thethreshold L_(th) mentioned in connection with the embodiments of FIGS.2, 3 and 4 a corresponds to min_(th). The congestion notificationprocedure of step S3 then consists in determining if the value ofQL_(av), which was found to exceed min_(th) in step S2, exceedsmax_(th), or if it lies between min_(th) and max_(th). This is shown asstep S31 in FIG. 6. It may be noted that these steps S31–S34 of FIG. 6can be used in the place of step S3 shown in FIGS. 2 and 3, i.e. thesteps S31 to S34 of FIG. 6 constitute a specific example of thecongestion notification procedure of step S3.

As shown in FIG. 6, if QL_(av) lies between min_(th) and max_(th), thenthe procedure goes to step S32, in which a probability p is calculatedin dependence on QL_(av). For example, a function p(QL_(av)) can bedefined that is linear and has a value p(min_(th))=0 and p(max_(th))=max_(p), where max_(p) is a maximum probability value thatcan be fixed, or can itself be an adaptive parameter. Naturally, othertypes of functions for p(QL_(av)) can be chosen as is suitable ordesirable.

Then, after step S32, a congestion notification is performed on a dataunit with the probability value P(QL_(av)) calculated in step S32, seestep S33. On the other hand, if the outcome of step S31 is negative,i.e. QL_(av) exceeds max_(th), then an unconditional congestionnotification operation is performed on a data unit in step S34.

The performance of the congestion notification operation in dependenceon the probability value p(QL_(av)) in step S33 can e.g. be conducted insuch a way that a random process is conducted using the probability as aweight, where the random process generates a “yes” or “no”, and the“yes” is generated with the probability p (QL_(av)). Such procedures arewell known in the art and need not be further described here. If theoutcome of the process is “yes”, then a congestion notification isperformed and if the outcome is “no”, then no congestion notificationoperation is performed.

The congestion notification operation conducted in step S33 or step S34can be selected in any suitable or desirable way, and can for exampleconsist in an implicit congestion notification operation, such as thedropping of a data unit, or can consist in an explicit congestionnotification operation, such as the setting of an appropriatenotification flag in a data unit or the sending of an explicitnotification message (source quench). This has already been describedearlier, such that a repeated description is not necessary. It may benoted that the same type of congestion notification operation can beperformed in steps S33, S34, e.g. a dropping operation in both cases ora flagging operation in both cases, but it is equally well possible toperform one type of congestion notification operation in step S33 andanother in step S34, e.g. the congestion notification operation in stepS33 can be a data unit dropping action, whereas the congestionnotification operation of step S34 can be a flagging operation.

Furthermore, the procedure for determining a data unit on which thecongestion notification operation in step S33 or S34 is to be performed,can be selected in any suitable or desirable way. For example, thecongestion notification operation can always be performed on the lastarrived data unit, or a data unit from among the queue data units can beselected by a random process, or the first data unit in the queue can beselected. Such techniques for selecting a data unit for performing acongestion notification operation are known in the prior art, and anysuch known technique is applicable, such that a further description isnot necessary here.

In accordance with the present embodiment, which uses two thresholdsmin_(th) and max_(th), the adaptation procedure of step S4 (FIG. 2, 3)or S41 (FIG. 4 a) consists in first estimating the link capacity LCaccording to the equationLC=(RTT _(WC) +RTT)·DR  (2)where DR is the data rate of the link, RTT is the round trip time of thelink, and RTT_(WC) is a predetermined constant. Then the lower thresholdmin_(th) is determined as a function of the estimated link capacity LC,for example is set equal to said estimated link capacity LC, or setequal to said sum of LC and another predetermined constant ε. Finally,the upper threshold max_(th) is set equal to the sum of min_(th) and afurther predetermined constant.

Regarding the choice of the first predetermined constant RTT_(WC), thisconstant is preferably chosen to be an estimate of the overallworst-case end-to-end round trip time for data units being transportedover said link, where end-to-end implies from the data unit source tothe data unit destination, and where furthermore RTT_(WC) does notinclude the RTT contribution of the link itself. However, RTT_(WC)should not be set to infinitely high values, such that when using theInternet of the year 2001 as a basis, a value of 300 ms shouldpreferably not be exceeded. Due to the fact that on the other hand thevalue of RTT_(WC) should reflect a maximum RTT, namely a worst-case RTT,it is preferred that RTT_(WC) is set in the range of 200 ms to 300 ms,and more preferably in the range of 200 ms to 250 ms, using the Internetof the year 2001 as a basis.

Naturally, in other types of networks than the Internet, smaller rangesare possible, and also in the future Internet, depending on the increasein speed with respect to the present Internet of the year 2001.

The second predetermined constant ε may be zero, or a small value withrespect to typical link capacity values. For example, if the link has arated or maximum link capacity of LC_(max) then ε may be chosen in therange of 0 to 0.01·LC_(max). Equally, ε can be set to be the equivalentof a small number of data units, such as two or three.

Finally, regarding the third constant for calculating max_(th), thisthird constant is preferably a small number of data units, e.g. 3 to 6data units. If min_(th) and max_(th) are expressed in numbers of dataunits, then it is sufficient to add an integer in the range of 3–6 tomin_(th) in order to determine max_(th), and in the case that min_(th)and max_(th) are represented as data amounts (in bytes or bits), thenthe third constant will be determined as a predetermined data unit size(such as the maximum segment size) measured in an amount of data,multiplied by an integer in the range of 3–6.

The present embodiment of the invention using the adaptation of min_(th)(L_(th)) on the basis of above described equation (2) is preferablyapplied to a buffer for buffering IP packets in a network where the flowcontrol for sending out such IP packets operates according to theTransmission Control Protocol (TCP) or a protocol using a comparablecongestion control scheme, such as TCP-friendly rate control for ratebased protocols. Namely, the above described settings for the thresholdensure that a network-limited TCP sender (network-limited means that thenumber of packets that are in flight is limited by congestion control)will fully utilize its available bandwidth. It has been recognized bythe inventors of the present invention that a network-limited TCP sendershould be allowed to grow its send window to at least two times thecapacity of the pipe into which the packets are being fed, in order tofully utilize the available bandwidth across multiple load decreaseevents.

As already mentioned above, the first constant RTT_(WC) is preferablyset to a value that estimates a worst-case end-to-end round trip timefor data units that are buffered in the queue buffer 2 and pass over thelink 1. A more precise selection of this constant than simply setting itin the above mentioned range of 200 to 300 ms, can especially beachieved if the end-to-end round trip time can be estimated sufficientlywell. This will especially be the case if the queue being managedcontains data units belonging to one flow. A flow is identified by asource and destination address, the source and destination port numberand a protocol identifier. The definition and concept of a flow is wellknown in the art, e.g. in the context of TCP (transmission controlprotocol), such that a further explanation is not necessary here. Inthis case, a more precise estimation of the worst-case round trip timefrom end to end minus the link's round trip time is possible. It may benoted that typically a queue buffer will buffer data units belonging toa plurality of different flows. However, it is envisionable that thequeue buffer 2 provides a plurality of queues 20, where each queue isassociated with a given flow, and each queue is managed in accordancewith its own individual control parameters.

In the above described embodiment and the embodiment of FIG. 4 a, theautomatic threshold adaptation procedure was an updating procedure forthe one or more threshold values. In the following, another embodimentwill be described, in which the automatic threshold adaptation procedurecomprises a threshold change procedure that responds to the connectivitystate of the link. As shown in FIG. 4 b, which can be arranged in placeof steps S7 and S4 in FIG. 3, it is first determined in a step S72 ifthe connectivity state of link 1 has changed, and if this is the case,then a threshold change procedure S42 is initiated.

The determination in step S72 preferably simply determines if the link 1provides connectivity or not. In other words, it is determined if dataunits may be transported or not. The threshold change procedure of stepS42 is preferably arranged in such a way that when the connectivitystate of link 1 changes in such a way that no data units aretransported, e.g., the link is down, then the threshold L_(th) isincreased, e.g., by multiplying the momentary value by a predeterminedfactor fc. In other words, when the link loses connectivity, then theprocedure in step S42 increases the length threshold value from L_(th)to fc·L_(th).

As shown in FIG. 5, where steps S73 and S43 correspond to steps S72 andS42 of FIG. 4 b, the step of increasing the threshold L_(th) ispreferably followed by a step S44, in which it is determined whether theconnectivity has returned. If this is the case, then the flow advancesto step S45, in which the threshold is reset to a new value. Theresetting can be done back to the threshold prior to the increase, i.e.,the previously increased value is divided by the factor fc, or a newdetermination of L_(th) can be conducted, e.g. as explained previouslyin connection with the updating procedure for L_(th). In other words,one or more link characteristics are measured, such as the RTT and DR,and the new value of L_(th) is calculated according to a predeterminedfunction thereof, e.g., according to the above equation (2).

Although it is possible to immediately reset the length threshold valueL_(th) to the new value, it is preferable to only gradually change thevalue in dependence on the number of data units in the queue (themomentary queue length) at the time of resetting the threshold. Namely,if the threshold L_(th) is suddenly reduced, and the queue lengthrelated parameter used as a basis for initiating the congestionnotification procedure is suddenly larger than threshold L_(th), then alarge number of congestion notification operations (e.g., the droppingof a large number of data units) suddenly occurs. In order to avoidthis, the threshold resetting procedure of step S45 can be implementedin such a way that the high initial value of L_(th) is not immediatelyreset to the new value, but much rather first reduced to the momentaryvalue of the queue length related parameter (e.g., QL or QL_(av)) andthen subsequently reduced if the queue length related parameter isreduced, until the above calculated new value for L_(th) is reached.

The advantage of the above described link change procedure in dependenceon the connectivity state of the length is that an unnecessarycongestion notification operation in the event of a link outage isavoided. Especially in the event that the congestion notificationoperation consists in dropping data units, the threshold changeprocedure in dependence on link connectivity assures that the entireload of data units going into the buffer is absorbed or buffered at thelink during link outages, while data unit losses are prevented. Theunderlying assumption is that the bandwidth available to the data unitsis basically unchanged after the link outages. Therefore, theperformance of a congestion notification procedure would give the wronginformation to the end-points sending or receiving the data units, whichwould then typically respond with an unwarranted restriction of dataunits being sent.

As already mentioned previously, the steps S71, S41 of FIG. 4 a canreplace steps S7, S4 of FIG. 3, steps S72, S42 of FIG. 4 b can replacesteps S7, S4 of FIG. 3, and steps S73 to S45 of FIG. 5 can replace stepsS7, S4 of FIG. 3. Further, it is also possible to combine the updatingprocedure of FIG. 4 a with the threshold change procedure of FIG. 4 b orFIG. 5, e.g., by arranging steps S71, S41, S72, and S42 in series as areplacement for steps S7, S4 of FIG. 3.

Further, it may be mentioned that the method of the present inventioncan also be supplemented by an automatic threshold reduction procedurefor automatically reducing the length threshold value L_(th) independence on the current memory capacity available to the queue buffer2.

Although the present invention has been described with the help ofdetailed embodiments, these only serve to convey a better understandingof the invention, and are not intended to restrict the scope. The scopeof the present invention is defined by the appended claims. Referencesigns in the claims serve to make the claims easier to understand, andalso do not restrict the scope.

1. A method of controlling a queue buffer, said queue buffer beingconnected to a link and being arranged to queue data units in a queue,said method comprising: determining a value (QL; QL_(av)) of a lengthparameter related to the length of said queue; comparing said value (QL;QL_(av)) with a length threshold value (L_(th); min_(th); max_(th));and, performing a congestion notification procedure if said value (QL;QL_(av)) is equal to or greater than said length threshold value(L_(th); min_(th); max_(th)), wherein an automatic threshold adaptationprocedure automatically adapts said length threshold value (L_(th);min_(th); max_(th)) on the basis of one or more characteristics of saidlink.
 2. The method of claim 1, wherein said automatic thresholdadaptation procedure updates said length threshold value (L_(th);min_(th); max_(th)) at regular intervals.
 3. The method of claim 1,wherein said automatic threshold adaptation procedure comprisesdetermining whether one or more of said one or more characteristics haschanged, and updating said length threshold value (L_(th); min_(th);max_(th)) when a change has occurred.
 4. The method of claim 1, whereinone of said one or more characteristics is a parameter (RTT) indicativeof the time period that passes between the sending of a data unit oversaid link and the receipt of an associated acknowledgment message. 5.The method of claim 4, wherein one of said one or more characteristicsis the data rate (DR) provided by said link for sending said data units.6. The method of claim 5, wherein said automatic threshold adaptationprocedure comprises estimating a link capacity value (LC) anddetermining said length threshold value (L_(th); min_(th); max_(th)) onthe basis of said estimated link capacity value (LC).
 7. The method ofclaim 6, wherein said automatic threshold adaptation procedure comprisesestimating the link capacity value (LC) on the basis of the parameter(RTT) indicative of the time period that passes between the sending of adata unit over said link and the receipt of an associated acknowledgmentmessage, and the data rate (DR) provided by said link for sending saiddata units.
 8. The method of claim 7, wherein said link capacity value(LC) is estimated by determining the sum of a value of said parameter(RTT) indicative of the time period that passes between the sending of adata unit over said link and the receipt of an associated acknowledgmentmessage and a first predetermined constant (RTT_(WC)), and setting saidlink capacity value (LC) equal to the product of said sum and said datarate (DR).
 9. The method of claim 8, wherein said first predeterminedconstant (RTT_(WC)) represents an estimation of the maximum time periodthat passes between the sending of a data unit from its origin to itsdestination and the receipt of an associated acknowledgment message atits origin, excluding the time period that passes between the sending ofsaid data unit over said link and the receipt of an associatedacknowledgment message over said link.
 10. The method of claim 9,wherein said first predetermined constant (RTT_(WC)) is in the range of200 ms to 300 ms.
 11. The method of claim 6, wherein said lengththreshold value (L_(th); min_(th); max_(th)) is set equal to saidestimated link capacity value (LC).
 12. The method of claim 6, whereinsaid length threshold value (L_(th); min_(th); max_(th)) is set equal tothe sum of said estimated link capacity value (LC) and a secondpredetermined constant (ε).
 13. The method of claim 1, wherein saidlength threshold value (L_(th); min_(th); max_(th)) is a first lengththreshold value (min_(th)), said congestion notification procedurecomprises comparing said value (QL; QL_(av)) of a length parameter to asecond length threshold value (max_(th)) larger than said first lengththreshold value (min_(th)), and said automatic threshold adaptationprocedure comprises determining said second length threshold value(max_(th)) as the sum of said first length threshold value (min_(th))and a predetermined constant.
 14. The method of claim 1, wherein saidautomatic threshold adaptation procedure comprises a threshold changeprocedure arranged to automatically change the value of said lengththreshold value (L_(th); min_(th); max_(th)) depending on theconnectivity state of said link.
 15. The method of claim 14, whereinsaid threshold change procedure comprises determining whether saidconnectivity state allows the transmission of data units, and if theconnectivity state is such that no transmission of data units isallowed, increasing said length threshold value (L_(th); min_(th);max_(th)) according to a predetermined threshold increasing procedure.16. The method of claim 15, wherein said threshold increasing procedurecomprises multiplying the current length threshold value (L_(th);min_(th); max_(th)) by a predetermined factor (fc).
 17. The method ofclaim 16, wherein said predetermined factor (fc) is two.
 18. The methodof claim 15, wherein said threshold change procedure furthermorecomprises determining whether said connectivity state again allows thetransmission of data units after a threshold increasing procedure, andif the connectivity state is such that a transmission of data units isagain allowed, resetting said length threshold value (L_(th); min_(th);max_(th)) to a new value according to a predetermined thresholdresetting procedure.
 19. The method of claim 18, wherein said thresholdresetting procedure comprises returning the length threshold value(L_(th); min_(th); max_(th)) to the value before having performed thethreshold increasing procedure.
 20. The method of claim 18, wherein saidthreshold resetting procedure comprises adapting said length thresholdvalue (L_(th); min_(th); max_(th)) on the basis of the current values ofone or more characteristics of said link.
 21. The method of claim 18,wherein said threshold resetting procedure comprises gradually resettingsaid length threshold value (L_(th); min_(th); max_(th)) to said newvalue depending on the number of data units in said queue buffer. 22.The method of claim 21, wherein said threshold resetting procedurecomprises resetting said length threshold value (L_(th); min_(th);max_(th)) to the momentary value of the length (QL) of said queue, ifsaid momentary value of the length (QL) of said queue exceeds said newvalue, and gradually reducing said length threshold value (L_(th);min_(th); max_(th)) to the successively reducing momentary values of thelength (QL) of said queue, until said new value is reached.
 23. Themethod of claim 1, wherein said step of determining a value (QL;QL_(av)) of a parameter related to the length of said queue and saidstep of comparing said value (QL; QL_(av)) with a length threshold value(L_(th); min_(th); max_(th)) are performed at regular intervals.
 24. Themethod of claim 1, wherein said step of determining a value (QL;QL_(av)) of a parameter related to the length of said queue and saidstep of comparing said value (QL; QL_(av)) with a length threshold value(L_(th); min_(th); max_(th)) are performed when said buffer receives anew data unit to be sent over said link.
 25. The method of claim 1,wherein said congestion notification procedure comprises making a dataunit dropping decision for dropping or retaining a data unit.
 26. Themethod of claim 1, wherein said congestion notification procedurecomprises making a data unit flagging decision for setting or notsetting a congestion notification flag in a data unit.
 27. The method ofclaim 25, wherein said decision is made for a newly received data unit.28. The method of claim 1, wherein said length parameter (QL; QL_(av))related to the length of said queue is a current length (QL) of saidqueue.
 29. The method of claim 1, wherein said length parameter (QL;QL_(av)) related to the length of said queue is an average length(QL_(av)) of said queue.
 30. The method of claim 1, wherein said link isa wireless link.
 31. The method of claim 1, further comprising anautomatic threshold reduction procedure for automatically reducing thelength threshold value (L_(th); min_(th); max_(th)) in dependence on thecurrent memory capacity available to said queue buffer.
 32. The methodof claim 1, wherein said data units are Internet Protocol packets.